МДК.05.01 Проектирование и дизайн информационных систем

Лекция 2. Разработка ТЗ. Этапы создания. Разработка эскизного проекта. Разработка технического проекта.

Цель лекции: Сформировать понимание целей, структуры и содержания ключевых проектных документов на этапах предпроектного и технического проектирования ИС.

Ключевая мысль: Качественное проектирование на 80% определяет успех всего проекта. "Семь раз отмерь (спроектируй), один раз отрежь (напиши код)".

1. Введение: Жизненный цикл разработки ИС

Создание сложной ИС — это не кодирование, а проект. Любой проект требует тщательного планирования и проектирования. Упрощенно жизненный цикл можно представить так:

  1. Предпроектная стадия (анализ, формирование требований) -> Техническое задание (ТЗ)
  2. Проектирование (создание архитектуры и моделей) -> Эскизный проект (ЭП) -> Технический проект (ТП)
  3. Разработка (написание кода)
  4. Тестирование
  5. Ввод в эксплуатацию
  6. Сопровождение

Сегодня мы подробно разбираем первые два пункта.

2. Техническое задание (ТЗ)

Техническое задание (ТЗ) — это основной документ, определяющий цели, требования и порядок создания информационной системы. Он утверждается заказчиком и является основой для договора и критерием приемки готовой системы.

Этапы разработки ТЗ:

  1. Выявление и анализ требований: Интервью, опросы, анкетирование, анализ бизнес-процессов заказчика.
  2. Структурирование и документирование требований: Формализация собранной информации.
  3. Согласование с заказчиком: Обсуждение, уточнение, утверждение.

Типовая структура ТЗ (на основе ГОСТ 34.602-89):

1. Общие сведения:

  • Наименование системы и проекта
  • Наименования заказчика и разработчика
  • Основание для разработки (приказ, договор)

2. Назначение и цели создания системы:

Что будет делать система? Какую бизнес-проблему решает?

3. Характеристики объекта автоматизации:

Описание бизнес-процессов компании-заказчика

4. Требования к системе (Функциональные требования):

Самый важный раздел! Подробное описание того, что должна делать система. Часто оформляется в виде Use Case (вариантов использования) или пользовательских историй (User Stories).

Пример: "Система должна позволять пользователю регистрировать новый заказ, внося данные: ФИО клиента, товар, количество, дата отгрузки".

5. Нефункциональные требования:

Требования к производительности, безопасности, надежности, удобству использования (usability), масштабируемости.

Пример: "Время отклика системы при любом запросе не должно превышать 2 секунд при нагрузке до 100 concurrent пользователей".

6. Состав и сроки выполнения работ:

Этапы разработки и их сроки

7. Порядок контроля и приемки системы:

Как будут тестировать систему? Критерии приемки

8. Приложения: Могут включать схемы бизнес-процессов, глоссарий терминов

3. Эскизный проект (ЭП)

Цель этапа: Разработать и утвердить архитектурные и проектные решения высокого уровня. Ответить на вопрос: "Как в общих чертах мы будем реализовывать требования из ТЗ?"

Результатом этапа является пакет документов "Эскизный проект", который обычно включает:

Эскизный проект согласуется с заказчиком, чтобы убедиться, что разработчик правильно понял ТЗ и предлагаемые решения устраивают заказчика.

4. Технический проект (ТП)

Цель этапа: Разработать детальные проектные решения, на основе которых можно непосредственно писать код. Это углубление и детализация эскизного проекта.

Результатом этапа является пакет документов "Технический проект", который включает:

Технический проект — это последний этап, где всё продумывается на бумаге (в моделях), прежде чем начать дорогостоящий процесс написания кода.

5. Сравнительная таблица: ТЗ, ЭП, ТП

Критерий Техническое задание (ТЗ) Эскизный проект (ЭП) Технический проект (ТП)
Основной вопрос ЧТО сделать? (Требования) КАК в общих чертах? (Архитектура) КАК в деталях? (Реализация)
Уровень детализации Высокоуровневое описание Архитектурный уровень Детальный, низкоуровневый
Целевая аудитория Заказчик, руководство, аналитики Заказчик, архитекторы, team leads Разработчики, тестировщики, DevOps
Основное содержание Функциональные и нефункциональные требования Выбор технологий, схема компонентов, логика данных Схемы БД, API-спекы, алгоритмы, макеты UI
Правовой статус Основа для договора и приемки Основа для согласования архитектуры Инструкция для разработчиков

6. Заключение

  • Последовательная разработка ТЗ -> ЭП -> ТП позволяет выявить и исправить ошибки и недопонимание на самых ранних, наименее затратных этапах
  • Исправление ошибки на этапе проектирования в десятки раз дешевле, чем исправление в коде или после внедрения
  • Эти документы служат единственно верным источником истины для всех участников проекта: от заказчика до разработчика
  • Качество проектной документации напрямую влияет на скорость разработки, стоимость владения и итоговое качество информационной системы

Ответы на контрольные вопросы

1. Почему важно различать функциональные и нефункциональные требования?

Различение этих типов требований критически важно потому, что они:

  • Описывают разные аспекты системы: функциональные — что система делает, нефункциональные — как она это делает
  • По-разному влияют на архитектуру и технологический стек
  • Требуют разных подходов к тестированию
  • Помогают правильно расставить приоритеты и управлять ожиданиями заказчика
2. Назовите не менее трех методов сбора требований. Какой метод, на ваш взгляд, самый эффективный и почему?

Три метода сбора требований:

  • Интервью с пользователями и заказчиками
  • Наблюдение за рабочими процессами
  • Анализ существующих документов и систем

Самый эффективный метод — интервью, потому что он позволяет:

  • Получить глубокую качественную информацию и контекст
  • Задавать уточняющие вопросы и сразу прояснять неясности
  • Выявить скрытые потребности и "болевые точки"
  • Наладить доверительные отношения со стейкхолдерами
3. Что такое "стейкхолдер" и почему его важно идентифицировать в начале проекта?

Стейкхолдер (заинтересованное лицо) — это любой человек, группа или организация, которые оказывают влияние на проект или находятся под влиянием его результатов.

Идентификация стейкхолдеров в начале проекта важна, потому что это позволяет:

  • Выявить все потребности и ожидания от системы
  • Построить эффективную коммуникационную стратегию
  • Управлять рисками и предотвращать конфликты
  • Правильно определить границы и цели проекта
  • Обеспечить успешное принятие результата всеми участниками
4. Какие последствия могут быть для проекта, если требования сформулированы нечетко и неполно?

Нечеткие и неполные требования приводят к серьезным негативным последствиям:

  • Разработана не та система — продукт не соответствует реальным потребностям пользователей
  • Резкий рост бюджета и сроков из-за постоянных переделок и доработок
  • Конфликты с заказчиком и потеря деловой репутации
  • Демотивация команды разработки из-за бесконечных изменений
  • Невозможность корректного тестирования системы
  • Провал проекта и напрасная трата ресурсов
5. Соответствует ли требование "Система должна быть удобной" критериям SMART? Если нет, переформулируйте его.

Нет, не соответствует. Это требование нарушает практически все критерии SMART:

  • S (Конкретное) — Не определено, что значит "удобная"
  • M (Измеримое) — Нет метрик для оценки удобства
  • A (Достижимое) — Неясно, что именно нужно достигать
  • R (Релевантное) — Релевантно, но слишком размыто
  • T (Ограниченное во времени) — Нет временных рамок

Переформулированное требование по SMART:

"Новый библиотекарь должен быть способен самостоятельно выполнить операции поиска и выдачи книги за 5 минут после 30-минутного обучения, совершив при этом не более 1 ошибки."

  • Конкретное: Определены пользователь и конкретные операции
  • Измеримое: Измеряется время (5 мин) и количество ошибок (≤1)
  • Достижимое: Реализуемо при хорошем дизайне интерфейса
  • Релевантное: Напрямую связано с эффективностью работы
  • Ограниченное по времени: Ограничение в 5 минут на операцию